As computerized products for enjoying television and other multimedia forms expand across international markets, originators and distributors of multimedia programming known as Independent Data Providers (IDPs) have multiplied to provide programming content from many countries. Programming content usually consists of the program listings, which are transferred in a “data feed,” that is, a “programming data file” that supplies local programming distributors with enough programming content to fill locally available channels for a specified duration, usually measured in days. The amount of programming data to be delivered by an IDP is usually defined in a listings data agreement.
Each IDP uses a proprietary listings format to create a programming data file that can be received and processed into local programming by a receiving entity. These proprietary listings formats are sometimes similar to each other but more often are different from each other and/or incompatible with each other, and more importantly, are incompatible with the receiving entity's needs. Specifically, the insertion of channel information needed to achieve a channel “lineup” that really works in a given locality for the supplied programming content is haphazard, due to the varying proprietary listings formats. In some instances the proprietary formats vary because collections of listings (i.e., programs and schedules) and lineups (i.e., sets of channels on which the programs and schedules will be implemented) are created by different types of IDPs. IDPs that produce listings usually predominate over the IDPs that produce lineups resulting in proprietary formats that favor listings information but neglect complete and accurate lineup information.
Additionally, the varying proprietary listings formats do not reliably convey information that has been translated across languages spoken in different countries. It is not always the translation itself that is problematic. A correct translation may be linked incorrectly to the wrong program number, for instance, or a new program number may be unnecessarily adopted because of the new language translation, resulting in a loss of referential consistency and, in this instance, a plethora of program numbers for one program.
FIG. 1 shows a conventional programming data file delivery environment 100, in which delivery proceeds from three example IDPs 102, 104, 106 to a receiving entity 108. IDPs typically select programming from a relatively unlimited universe of program listings 110 to create a programming data file that is marketed to the receiving entity 108, i.e., a local programming distributor, such as local broadcast station or a television cable company. The programming data files are characteristically large and therefore require, for example, approximately twenty hours of processing time to convert the data file into usable form.
In creating a programming data file, IDPs typically emphasize program listings 110 information, such as the names of movies and programs, to the exclusion or haphazard inclusion of supporting “lineup” logistical information that would be necessary to present programs at given times on specific channels available in the receiving entity's locale or catchment area. Although most IDPs add schedule information, attempts to include consistent and correct lineup information usually prove insufficient, as discussed above, especially when programming data files are transferred between different countries.
The blend of information formulated in a proprietary programming data file and the proprietary formats used may vary widely between IDPs. Thus, as shown in FIG. 1, a first IDP 102 uses a first proprietary data file format 112, a second IDP 104 uses a second proprietary data file format 114, and a third IDP 106 uses a third proprietary data file format 116. A receiving entity 108, such as a local programming distributor may even subscribe to several IDPs and must process programming data files from each into programming 109. Often, after spending, for example, twenty hours of processing time to convert a programming data file into usable programming 109, the receiving entity 108 discovers that one or more aspects of a proprietary format are not consistent 118. Perhaps channels listed in the programming data file do not exist 120 or do not exist in the local supplier's geographical and/or geopolitical area. Since the data file formats 112, 114, 116 from the various IDPs are arbitrary, data elements may be missing 122, the data may contradict itself 124, and/or the data may be present but may be unusable because incorrect and/or unrecognizable data types have been used 126. Because the data file is partially or completely defective, part or all of the processing time investment may be lost, and troubleshooting may be needed.